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ABSTRACT 


A  description  is  given  of  the  procedure  structvire  in  the  TRANQUIL 
compiler,  which  allows  external  and  internal  procedures  which  may  or  may  not 
return  a  single  value.  Also,  for  the  benefit  of  those  who  may  have  to  change 
the  compiler,  a  description  is  given  of  the  current  implementation. 
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1.   INTRODUCTION 

TRANQUIL  is  a  high-level  algorithmic  language  for  ILLIAC  TV  pro- 
grajraning.   The  TRANQUIL  compiler  is  currently  being  written  to  run  on  the 
B65OO  and  produce  ILLIAC  IV  assembler  code  which  will  then  be  input  to  the 
assembler  (ASK),  also  to  run  on  the  B65OO.   The  latter  will  output  executable 
ILLIAC  IV  machine  code.   This  report  describes  the  procedure  facility  in 
TRANQUIL  and  assimes  that  the  reader  has  a  knowledge  of  other  parts  of  TRANQUIL 
(Abel,  Budnik,  Kuck,  Miiraoka,  Northcote  and  Wilhelmson  [l]  provide  a  good  in- 
troduction to  TRANQUIL)  and  of  ILLIAC  IV. 

Syntactically,  TRANQUIL  resembles  the  major  block  structure  lan- 
guages now  in  use,  i.e.,  ALGOL  and  PL/1,  and  is  particularly  modelled  after 
ALGOL.   In  creating  a  procedure  facility  for  TRANQUIL,  the  procedure  facil- 
ities provided  in  ALGOL  and  PL/1  have  been  used  as  a  model.   Since  ILLIAC  TV 
is  structured  such  that  all  processing  elements  execute  the  same  instruction 
in  parallel,  about  the  only  difference  that  might  be  expected  from  the  pro- 
cedure structure  of  languages  designed  for  conventional  machines  would  be  the 
ability  to  return  an  array  of  values.  However,  since  TRANQUIL  arrays  often 
contain  more  elements  than  can  be  operated  on  in  parallel  simultaneously, 
this  would  mean  finding  storage  for  the  array  of  values.   Since  the  same 
effect  can  always  be  achieved  by  passing  an  array  as  a  parameter  and  since, 
in  many  cases,  the  array  thus  created  would  be  immediately  substituted  into 
another  array  thus  making  poor  use  of  storage,  and  since  the  storage/ computing 
power  ratio  is  quite  low  in  ILLIAC  TV,  such  array  procedures  have  not  been 
implemented  in  TRANQUIL.  However,  iinder  certain  restrictions,  TRANQUIL  may 
communicate  with  procedures  written  in  assembly  language  which  return  differ- 


ent  values  in  each  processing  element.  In  this  regard,  it  is  interesting  to 
note  that  PL/1,  which  does  allow  array  operations,  does  not  allow  user  defined 
functions  to  return  more  than  a  single  value.  ALGOL,  of  course,  also  does  not 
allow  functions  to  return  an  array  of  values. 

Between  ALGOL  and  PL/1,  three  ways  of  passing  parameters  to  proce- 
dures may  be  discerned:  passing  parameters  by  value,  by  address,  and  by  name. 
When  a  parameter  is  passed  by  value,  its  value  is  available  to  the  procedure, 
but  not  its  address.  In  B5500  ALGOL  and  System /360  PL/1,  a  parameter  passed 
by  value  causes  a  dummy  location  to  be  initialized  to  that  value  so  that  the 
formal  parameter  may  be  manipulated  within  the  procedure  without  affecting  the 
actual  parameter.  When  a  parameter  is  passed  by  address,  its  address  is  made 
available  to  the  procedure  so  that  any  changes  in  the  formal  parameter  are  re- 
flected in  the  actual  parameter.  When  a  parameter  is  passed  by  name,  each 
use  of  the  formal  parameter  within  the  procedure  causes  a  subroutine   (often 
referred  to  as  a  thunk,  see  Ingerman  [2])  to  be  called  which  evaluates  the 
actual  parameter.   In  PL/1,  parameters  may  be  passed  by  value  or  by  address. 
Passing  by  value  is  implicit  since  it  occurs  whenever  an  expression  is  recog- 
nized in  the  calling  sequence.   In  ALGOL,  parameters  may  be  passed  by  value 
or  by  name.   Passing  by  value  is  explicit  since  certain  parameters  to  a  pro- 
cedure may  be  declared  in  the  procedure  heading  as  being  passed  by  value. 
Placement  of  an  expression  in  a  calling  sequence  causes  generation  of  a  thunk 
to  evaluate  that  expression.   In  TRANQUIL  parameters  may  be  passed  by  address 
or  by  value.   Both  explicit  and   implicit  passing  by  value  are  allowed  since 
parameters  may  be  explicitly  declared  to  be  passed  by  value  in  the  procedure 
heading  or  parameters  may  be  implicitly  passed  by  value  by  placing  an  expres- 
sion as  an  actual  parameter  in  the  calling  sequence.   It  should  be  emphasized 
that  only  sijnple  variables  may  be  passed  by  value.   Passing  parameters  by 


name  has  not  been  implemented  in  TRANQUIL  since  it  is  felt  that  the  benefits 
to  be  gained  are  marginal  (and,  in  fact,  passing  parameters  by  name  has  been 
known  to  create  some  bizarre  error  conditions  in  ALGOL  programs)  compared  to 
the  difficulty  in  implementation  and  the  extra  execution  time  required  to 
evaluate  the  thunks  on  ILLIAC  IV. 

Another  important  topic  is  external  (i.e.,  separately  compiled  or 
assembled)  procedures.   PL/1  explicitly  allows  external  procedures  whereas 
formal  ALGOL  and  B5500  ALGOL  do  not.   TRANQUIL  does  allow  external  procedures 
for  several  reasons.  First,  since  ILLIAC  IV  was  not  designed  with  TRANQUIL 
(or  any  other  higher  level  language)  in  mind,  it  is  to  be  expected  that  some 
routines  may  be  more  efficiently  coded  in  assembly  language  than  in  TRANQUIL. 
However,  particularly  in  lengthy  programs,  users  would  find  it  too  tedious  to 
code  an  entire  program  in  assembly  language  and  could,  therefore,  code  as  ex- 
ternal procedures  those  routines  which  they  consider  absolutely  crucial  in 
timing.   The  approach  of  formal  ALGOL  in  allowing  internal  procedures  to  be 
written  in  code  other  than  ALGOL  would  not  be  sufficient  since  it  is  expected 
that  many  of  the  high  speed  routines  would  be  part  of  a  subroutine  library, 
possibly  maintained  by  different  people  than  the  users  writing  TRANQUIL  pro- 
grams and,  therefore,  it  would  be  difficult  if  not  impossible  for  each  user  to 
update  code  procedures  in  his  program.  Another  reason  for  having  external 
procedures  is  to  cut  down  compilation  time  when  a  change  is  made  to  a  long 
program.   Experience  has  proven  that  the  necessity  to  recompile  an  entire 
long  program  in  order  to  insert  even  a  small  change,  as  must  be  done  in  B5500 
ALGOL,  is  highly  undesirable.   Since  the  TRANQUIL  compiler  will,  due  to  the 
complex  analysis  which  must  be  performed  in  order  to  make  efficient  use  of 
the  parallelism  of  ILLIAC  IV,  run.   more  slowly  than  many  compilers,  the  bene- 
fits derived  from  being  able  to  break  a  TRANQUIL  program  into  several  inde- 
pendently compilable  procedures  should  be  quite  substantial. 
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Finally,  there  is  the  question  of  recursion.  ALGOL  allows  all  pro- 
cedures to  be  recursive.   PL/1  allows  only  procedures  which  have  the  attribute 
"recursive"  to  be  recursive.   In  B5500  ALGOL,  recursion  is  quite  easy  to  mple- 
ment  due  to  the  stack  structure  of  the  machine.  In  System/360  PL/1,  recursion 
involves  pushing  back  all  core  used  by  the  procedure  for  data  with  an  appro- 
priate pointer  so  that  it  may  be  recalled  and  recursion  is,  therefore,  very 
time  consuming.   In  TRANQUIL  recursion  is  not  allowed,  at  present,  due  to  stor- 
age allocation  problems  and  the  extra  execution  time  which  would  be  required 
to  keep  track  of  either  a  programmed  stack  or  links  to  blocks  of  storage  from 
earlier  calls  to  the  procedure. 

In  summary,  then,  the  procedure  facility  in  the  TRANQUIL  compiler 
allows  typed  (returning  a  single  value)  and  non-typed  procedures.  Procedures 
may  be  external  or  internal  (to  the  main  program).   External  procedures  may 
be  written  in  TRANQUIL,  or  ASK,  or  any  other  language  which  is  now,  or  may  in 
the  future  be,  implemented  for  ILLIAC  IV,  provided  that  TRANQUIL  conventions 
are  followed.  Any  type  of  variable  allowed  in  TRANQUIL  may  be  passed  as  a 
parameter,  i.e.,  parameters  may  be  simple  variables  (arithmetic  or  boolean), 
arrays,  sets,  labels,  switches,  or  procedures.   Of  these,  simple  arithmetic 
and  boolean  variables,  may  be  passed  either  by  value  or  by  address  while  the 
others  may  be  passed  by  address  only.  Recursion  and  passing  parameters  by  name 
are  not  implemented. 


2.   THE  SPECIFICATION  OF  PROCEDURES  IN  TRANQUIL 

2.1  Placement  of  the  Procedure  Declaration 

As  in  ALGOL,  a  procedure  is  considered  to  be  a  declaration.   Since 
TRANQUIL  has  the  same  block  structure  as  ALGOL,  internal  TRANQUIL  procedures 
must  be  placed  in  a  block  head.  Also,  a  procedure  declaration,  or  an  EXTER- 
NAL ENTRY  declaration,  must  occur  before  any  call  on  that  procedare.  A  dec- 
laration for  an  internal  procedure  consists  of  the  procedure  heading  followed 
by  the  procedure  body.   The  procedure  heading  contains  the  specification  for 
the  parameters  while  the  procedure  body  consists  of  a  block  (which,  of  course, 
may  contain  nested  blocks)  of  code  which  is  to  be  executed  when  the  procedure 
is  invoked.   The  declaration  for  an  external  procedure  consists  of  optionally 
listing  the  type  of  the  procedure  (if  it  is  to  return  a  value)  along  with  the 
specification  of  the  parameters.   Since  it  is  not  possible  to  access  an  ex- 
ternal procedure  at  compile  time  to  determine  agreement  between  actual  and 
formal  parameters,  the  agreement  is  checked  and  the  proper  call  is  set  up  by 
checking  the  declaration  (known  as  an  EXTERNAL  ENTRY  declaration)  which  occurs 
in  the  calling  program.   In  order  to  create  an  external  procedure  written  in 
TRANQUIL,  the  entire  TRANQUIL  program  is  set  up  as  an  EXTERNAL  PROCEDURE  dec- 
laration (not  to  be  confused  with  an  EXTERNAL  ENTRY  declaration)  which  is 
simply  a  procedure  declaration  preceded  by  the  word  "EXTERNAL." 

2.2  The  Procedure  Heading 

The  procedure  heading  consists  of  specifying  the  name  of  the  pro- 
cedure, its  type  (if  it  returns  a  value),  and  the  names  and  types  of  the  para- 
meters, if  any.   For  example,  a  procedure  P  which  returns  a  REAL  (6U-bit 
floating  point)  value  and  has  no  parameters  would  have  the  heading: 


REAL  PROCEDURE  P; 
If  P  did  not  return  a  value  it  would  have  as  a  heading  simplj: 

PROCEDURE  P; 
The  parameter  specifications  are  quite  similar  to  the  declarations 
for  the  same  type  of  variables.   They  will  now  "be  described  for  the  various 
types  of  variables  which  may  be  passed  as  parameters. 

2.2.1  Simple  Arithmetic  and  Boolean  Variables 

The  specifications  for  simple  arithmetic  and  boolean  variables  are 
exactly  the  same  as  the  declarations  for  these  kinds  of  variables.   These  vari- 
ables may  be  passed  by  value  in  which  case  the  interpretation,  as  in  B5500 
ALGOL,  is  that  a  local  variable  in  the  procedure  is  initialized  to  the  value 
of  the  actual  parameter  but  may  then  be  changed  arbitrarily  by  computations 
within  the  procedure  without  affecting  the  actual  parameter.   The  VALUE 
specification  is  the  same  as  in  ALGOL,  namely,  "VALUE"  followed  by  the  identi- 
fier list.   If  VALUE  specifications  are  used,  they  must  appear  before  all  other 
specifications  in  the  procedure  heading. 

If  the  formal  parameter  is  boolean,  then  the  actual  parameter  must  be 
a  boolean  expression  or  a  boolean  variable.   If  the  formal  parameter  has  an 
arithmetic  type  (i.e.,  REAL,  INTEGER,  etc.),  then  the  actual  parameter  must  be 
an  arithmetic  variable  or  an  arithmetic  expression  returning  a  single  value.   If 
the  actual  and  formal  parameters  disagree  as  to  arithmetic  types,  then  type 
conversion  will  be  performed  on  entry  to  the  procedure  and,  in  the  case  of  call 
by  address,  type  conversion  in  the  opposite  direction  will  be  performed  on  exit 
from  the  procedure  in  order  to  return  the  updated  value  of  the  variable  in  the 
form  required  by  the  attributes  of  the  actual  parameter  in  the  calling  block. 
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If  axi  expression  (arithmetic  or  boolean)  is  passed  by  address,  then 
the  parameter,  for  that  one  particular  call,  is  treated  as  being  passed  im- 
plicitly by  value  and  is  handled  in  the  same  fashion  as  if  it  were  explicitly 
passed  by  value.  At  present  an  array  element  given  as  the  actual  parameter 
for  an  arithmetic  formal  parameter  is  treated  as  an  arithmetic  expression  and 
is,  therefore,  implicitly  passed  by  value. 

As  an  example  of  a  procedure  heading  using  boolean  and  arithmetic 
variables,  consider: 

PROCEDURE   VTEST  (A,  B,  C,  D); 

VALUE  B,  C; 

INTEGER  A,  C;  BOOLEAN  B;   REAL  D; 

The  procedure  VTEST  is  a  non-typed  procedure  with  four  parameters.  A,  B,  C, 
D  of  which  two,  B  and  C,  are  passed  by  value.  A  and  C  are  handled  as  type 
INTEGER  within  the  procedure,  B  as  type  BOOLEAN  and  D  as  type  REAL.   If  the 
actual  parameters  corresponding  to  A,  C,  or  D  are  of  a  different  arithmetic 
type,  type  conversion  will  be  performed  at  the  procedure  call. 

2.2.2  Arrays 

Arrays  may  be  passed  by  address  only.   The  formal  and  actual  para- 
meter arrays  must  agree  as  to  mapping  function,  type,  and  number  of  dimensions. 
In  specifying  an  array  in  the  procedure  heading,  the  mapping  function,  formal 
parameter  identifier,  and  dimension  information  must  be  given.   The  dimension 
information  may,  for  each  dimension,  be  either  an  asterisk  ("■>«■")  or  an  integer. 
If  an  asterisk  is  used,  then  the  formal  parameter  array  takes  on  the  same  lower 
bound  in  the  corresponding  dimension  as  the  actual  parameter  array.   If  an 


integer  is  used,  then  the  formal  parameter  array,  in  that  dimension,  takes  on 
the  given  integer  value  as  the  lower  bound.   In  either  case,  the  size  of  each 
dimension  remains  the  same  in  the  formal  parameter  array  as  in  the  actual  par- 
ameter array.  Also,  in  the  specification  of  any  one  array,  the  use  of  aster- 
isks and  integers  may  be  mixed  in  any  fashion. 
For  example,  if 

PROCEDURE  ATEST  (A,  B,  C); 
REAL  SKEWED  ARRAY  A[*,  *,  *]; 
INTEGER  STRAIGHT  ARRAY  B[10,  *]; 
REAL  STRAIGHT  ARRAY  C[3]; 

is  written,  then  the  procedure  ATEST  has  three  parameters.   The  first  para- 
meter (a)  is  a  three  dimensional  REAL  SKEWED  array,  all  of  the  dimensions  of 
which  are  to  have  the  same  lower  bound  as  in  the  actual  parameter  array.   The 
second  parameter  (b)  is  a  two-dimensional  INTEGER  STRAIGHT  array.   The  first 
dimension  is  to  have  a  lower  bound  of  10,  regardless  of  the  first  dimension  of 
the  actual  parameter  array,  but  will  have  the  same  size  as  the  first  dimen- 
sion of  the  actual  parameter  array.   The  second  dimension  will  have  the  same 
lower  bound  as  the  actual  parameter  array.   The  third  parameter  (C)  is  a  one- 
dimensional  REAL  STRAIGHT  array  and  that  one  dimension  will  have  a  lower  bound 
of  3. 

2.2.3  Sets 

Sets  passed  as  parameters  must  agree  as  to  type  of  set  and  nimiber 
of  dimensions  (the  present  implementation  supports  only  one-dimensional  sets, 


however).   Sets  may  be  passed  by  address  only.   In  the  example: 

PROCEDURE  STEST  (Sl,  S2,  S3); 
INCSET  SI; 
GENSET  S2; 
MONOSET  S3;, 

the  procedure  STEST  has  three  parameters,  the  first  being  an  INCSET,  the 
second  a  GENSET,  and  the  third  a  MONOSET. 

2.2.U  Labels 

Labels  may  be  passed  as  parameters.   The  only  requirement  on  the 
actual  parameter  is  that  the  label  be  defined  at  the  point  of  procedure  call. 
The  action  on  transferring  to  a  label  passed  as  a  parameter  is  to  jump   to  the 
end  of  the  procedure,  then  to  the  point  of  call,  and  finally  to  the  specified 
label.   For  example,  in 

PROCEDUEE  LTEST  (L1);  LABEL  LI; 

the  procedure  LTEST  is  an  untyped  procedure  with  one  parameter,  a  label. 

2.2.5  Procedures 

Procedures  may  be  passed  as  parameters  to  other  procedures.  Unlike 
the\  case  in  ALGOL,  the  parameters  of  a  proced\ire  passed  as  a  parameter  must 
be  fully  specified.  The  fomial  and  actual  parameter  procedures  must  agree  as 
to  type  (if  they  are  both  typed  procedures),  or  both  must  be  untyped  pro- 
cedures, and  both  must  have  the  same  number  of  parameters.   In  addition,  the 
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parameters  to  the  actual  and  formal  parameter  procedures  must  agree.  That  is, 
if  a  parameter  in  one  is  an  arithmetic  simple  variable,  then  the  corresponding 
parameter  in  the  other  must  be  a  simple  arithmetic  variable  of  the  same  type. 
If  the  parameter  to  one  is  a  boolean  variable,  then  the  parameter  to  the  other 
must  also  be  a  boolean  variable.   In  addition,  in  the  case  of  simple  arithmetic 
and  boolean  variables,  if  the  parameter  in  one  of  the  procedure  parameters  is 
specified  by  VALUE,  then  the  parameter  in  the  other  must  also  be  specified  by 
VALUE.   In  the  case  of  arrays,  the  parameters  must  agree  as  to  mapping  func- 
tions, type,  and  number  of  dimensions.   For  sets,  the  parameters  must  agree 
as  to  type  of  set.  For  labels  or  switches,  both  parameters  must  be  either 
labels  or  switches,  respectively.  For  procedures,  the  parameters  must  agree 
as  to  type  (or  be  both  untyped)  and,  in  addition,  the  parameters  of  the  two 
must  agree  as  outlined  above. 

In  specifying  the  parameters  of  a  procedure  passed  as  a  parameter, 
the  attributes  only  (not  identifier  names  since  these  are  given  in  the  heading 
of  the  actual  parameter  procedure)  are  listed  in  parentheses  following  the 
name  of  the  procedure.   If  the  procedure  which  itself  is  a  parameter  has 
another  procediire  as  a  parameter,  then  the  attributes  of  the  parameters  of 
the  latter  procedure  are  listed  in  parentheses  following  the  word  "PROCEDURE." 

Consider,  for  example,  the  following  procedure  heading: 


PROCEDURE  PTEST  (Pl,  P2); 

REAL  PROCEDURE  PI  (VALUE  REAL,  INTEGER, 
INCSET,  REAL  SKEWED  ARRAY  [*,  *]); 

IIWEGER  PROCEDURE  P2  (BOOLEAN, 
PROCEDURE  (real)); 
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Here,  procedure  PTEST  has  two  parameters,  PI  and  P2.   PI  is  a  REAL  procedure 
which  has  four  parameters.   The  first  is  of  type  REAL  passed  by  value.   The 
second  is  INTEGER  passed  by  address.   The  third  is  a  set  which  is  defined  as 
an  INCSET  (increment  set).   The  fourth  is  a  two-dimensional  REAL  SKEWED  array 
(note  that  only  "*"  is  used  to  describe  a  dimension.   If  an  integer  is  to 
appear  as  the  lower  bound,  it  will  appear  in  the  procedure  heading  of  the 
actual  parameter  procedure) .   The  second  parameter  of  PTEST  is  P2,  an  INTEGER 
procedure.   The  first  parameter  of  P2  is  a  BOOLEAN  variable  and  the  second 
parameter  is  an  untyped  procedure  which  has  a  single  parameter,  a  REAL  simple 
variable. 

2.3  The  EXTERNAL  ENTRY  Declaration 

When  an  external  procedure  is  to  be  called  from  a  TRANQUIL  program, 
an  EXTERNAL  ENTRY  declaration  which  specifies  the  type  both  of  the  procedure 
(if  the  external  procedure  is  to  return  a  value)  and  the  parameters  must  be 
provided.   The  parameters  are  specified  in  exactly  the  same  fashion  as  for  a 
procedure  passed  as  a  parameter  (see  Section  2.2.5  above),  only  the  attributes 
of  the  parameters,  in  parentheses,  follow  the  procedure  identifier  in  the 
EXTERNAL  ENTRY  statement.   The  agreement  between  formal  and  actual  parameters 
is  the  same  as  for  any  other  proced\ire. 

As  an  example,  consider 

EXTERNAL  INTEGER  ENTRY  ETEST  (REAL, 
VALUE  INTEGER,  REAL  STRAIGHT  ARRAY  [*,*], 
INCSET) ; 
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Then  the  program  in  which  the  above  declaration  occiirs  will  expect  to  have 
access  to  an  external  procedure  ETEST  which  has  foiir  parameters,  a  REAL  para- 
meter passed  by  address,  an  INTEGER  parameter  passed  by  value,  a  two  dimen- 
sional REAL  STRAIGHT  array,  and  an  INCSET. 

2.4  The  Procedure  Body 

2.U.1  General  Description 

The  procedure  body  is  a  TRANQUIL  block,  if  it  is  programmed  in  TRAIT- 
QUIL-   The  parameters  are  treated  as  being  declared  in  a  block  external  to  the 
procediore  body  (and  are,  therefore,  global  to  the  procedure  body)  but  internal 
to  the  block  in  which  the  procedure  declaration  resides  (so  that  the  para- 
meters may  not  be  used  anywhere  outside  the  procedure) .  Therefore,  in  partic- 
ular,  identifier  names  the  same  as  those  of  the  parameters  may  be  redeclared 
in  a  block  internal  to  the  procedure  and,  when  used  in  that  block,  will  be 
accessed  as  variables  local  to  that  block  rather  than  as  parameters  to  the 
procedure  which  contains  that  block.   In  other  respects,  the  body  of  a  TRAJNIQUIL 
procedure  is  like  any  other  block  in  a  TRAUQUIL  program  with  the  exception  of 
the  use  of  the  RETURN  statement  and  jumping  to  labels,  in  certain  cases. 

2.U.2  The  RETURN  Statement 

The  RETURN  statement  is  used  to  exit  from  a  procedure.   If  a  value 
is  to  be  returned,  then  the  RETURN  statement  must  be  used  to  return  the  value. 
If  no  value  is  to  be  returned,  then  the  use  of  the  RETURN  statement  is  optional 
since  a  procedure  is  also  exited  when  the  flow  of  control  passes  through  the 
end  of  the  procedure  body.   RETURN  statements  may  occur  anywhere  in  a  procedure 
body  and  any  number  of  RETURN  statements  may  be  used. 
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In  order  to  return  a  value  from  a  procedure,  the  value  (which  may  be 
a  constant  or  an  expression  which  returns  an  appropriate  value)  is  placed  in 
parentheses  following  the  word  "RETURN"."  Execution  of  such  a  RETURN  statement 
causes  an  exit  to  be  made  from  the  procedure  body  and  the  value  generated  to 
be  the  value  returned  from  the  procedure. 

A  RETURN  with  value  may  be  used  only  in  a  typed  procedure  and  the 
value  returned  must  be  arithmetic  if  the  type  of  the  procedure  is  arithmetic 
and  boolean  if  the  type  of  the  procedure  is  boolean.  An  arithmetic  value  is 
converted  to  the  type  of  the  procedure  if  it  is  not  already  that  type.  A 
RETURN  without  a  value  may  be  made  from  a  typed  procedure,  in  which  case  a 
default  of  zero  is  assigned  if  the  type  of  the  procedure  is  arithmetic  and 
FALSE  is  assigned  if  the  type  of  the  procedure  is  boolean. 

As  an  example,  the  statement 

RETURN  (A+B); 

causes  exit  to  be  made  from  a  procedure  and  the  value  of  A+B  to  be  returned. 
The  statement 

RETURN; 

causes  exit  to  be  made  from  a  procedure  without  returning  any  value  and  thus 
may  be  used  in  a  typed  or  untyped  procedure. 

2.U.3  Use  of  Labels 

Within  a  procedure,  transfer  may  be  made  to  other  labels  also  within 
the  procedure  body,  subject  to  the  usual  rules  and  restrictions  for  TRANQUIL 
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programs.  However,  transfer  may  not  be  made  to  a  label  occurring  outside  the 
procedure  body  unless  that  label  is  passed  as  a  parameter  to  the  procedure 
and  the  label  is  accessible  at  the  procedure  call. 

2 . 5  External  Procedure  Declarations 

An  EXTERNAL  PROCEDURE  declaration  is  sijnply  a  procedure  declaration 
preceded  by  the  word  "EXTERNAL."  An  external  procedure  is  intended  to  permit 
separate  compilation  (and  assembly)  from  other  TRANQUIL  programs.  Therefore, 
the  heading  for  the  external  procedure  must  be  the  first  compilable  code  sub- 
mitted to  the  TRANQUIL  compiler  when  an  external  procedure  is  desired  and  an 
EXTERNAL  PROCEDURE  declaration  may,  therefore,  occur  at  most  once  in  a  single 
compilation  (this  should  be  distinguished  from  the  EXTERNAL  ENTRY  declaration 
which  may  occur  as  often  as  desired  and  may  occur  wherever  a  declaration  is 
permitted) .  In  all  other  respects,  an  external  procediore  is  like  an  internal 
procedure. 

As  an  example,  consider  the  following  trivial  EXTERNAL  PROCEDURE 
declaration. 

EXTERNAL  INTEGER  PROCEDURE  ETEST  (A,B); 
VALUE  A,  B;   INTEGER  A,  B; 
BEGIN 

RETURN  (A+B); 
END. 

Procedure  ETEST  would  return  the  integer  sura  of  its  two  integer  parameters. 
Procedure  ETEST  would  be  separately  compiled  from  the  calling  program,  which 
may  not  even  be  written  in  TRANQUIL. 
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2.6  ROW  Procedures 

Row  procedures  are  a  special  type  of  external  procedure  which  must 
be  written  In  ASK.   The  function  of  a  row  procedure  Is  to  take  values  In  RGA, 
perform  some  computation  on  these  values,  and  return  the  result  to  RGA.   The 
returned  results  should  occur  only  In  those  PE's  which  were  enabled  at  the 
time  of  the  call  and  the  setting  of  the  mode  bits  should  thus  be  the  same  at 
the  return  as  at  the  call.  A  row  procedure  has  a  single  parameter,  which  is 
specified  as  a  simple  arithmetic  variable  (in  order  to  allow  type  conversion). 
The  chief  use  of  row  procedures  will  be  to  do  parallel  computations  on  arrays 
within  SIM  loops. 

The  EXTERNAL  ENTRY  declaration  for  a  ROW  procedure  is  like  the 
EXTERNAL  ENTRY  declaration  for  any  other  procedure  except  that  the  word  "ROW" 
precedes  the  word  "ENTRY."  A  ROW  procedure  should  be  typed  in  order  that 
proper  conversion  may  be  performed  on  the  returned  values.  For  example, 

EXTERNAL  REAL  ROW  ENTRY  RTEST(REAL); 

RTEST  is  then  assumed  by  the  calling  program  to  be  a  ROW  procedure  which 
operates  on  real  values  from  RGA  in  all  enabled  PE's  and  returns  (computed) 
real  values  in  RGA  in  these  same  PE's,  while  not  changing  other  PE's  or 
the  mode  bit  setting. 

2  -7   The  Proced\ire  Call 

As  in  ALGOL,  the  procedure  call  consists  of  the  name  of  the  pro- 
cediire  followed  by  the  list  of  actual  parameters,  in  parentheses.   If  there 
are  no  actual  parameters,  then  the  procedure  call  consists  simply  of  the 
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procedirre  Identifier.  The  number  of  formal  and  actual  parameters  must  be  the 
same.  Additional  required  agreements  for  various  kinds  of  parameters  are  as 
specified  in  Section  2.2  above. 

If  the  formal  parameter  is  an  arithmetic  simple  variable,  then  the 
actual  parameter  may  be  an  expression  returning  a  single  arithmetic  value. 
If  the  formal  parameter  is  a  boolean  variable,  then  the  actual  parameter  may 
be  an  expression  returning  a  single  boolean  value.   In  all  other  cases,  the 
actual  parameter  must  be  an  identifier  and  its  specifications  must  agree  with 
those  of  the  corresponding  formal  parameter. 

A  procedTore  call  (except  to  a  ROW  procedure  which  should  be  used  in 
an  expression  within  a  SIM  loop)  may  occur  as  a  distinct  statement  whether  or 
not  the  procedure  is  typed  (if  the  procedure  is  typed,  the  value  returned  will 
be  lost).   In  addition,  a  call  to  a  typed  procedure  returning  an  arithmetic 
value  may  appear  in  an  arithmetic  expression  and  a  call  to  a  typed  procedure 
returning  a  boolean  value  may  appear  in  a  boolean  expression.   Any  other  com- 
bination of  type  of  expression  and  type  of  procedure  is  not  permitted. 

Consider,  for  example,  the  procedure  heading 

INTEGER  PROCEDURE  CTEST(A,  B); 
REAL  A;   INCSET  B; 

Let  X  and  Y  be  declared  as  REAL  simple  variables  and  let  J  be  an  IWCSET. 
Then  the  following  two  statements  represent  permissible  calls  to  procedure 
CTEST : 

X:  =  CTEST.(X+Y,J); 
CTEST(X,J); 
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In  the  second  case,  the  value  of  CTEST  is  lost,  but  side  effects  may  have 
occurred. 
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3 .   IMPLEMENTATION 

This  section  is  intended  primarily  to  document  actual  work  done  on 
the  TRANQUIL  compiler  for  the  benefit  of  those  who  may  have  occasion  to  modify 
those  portions  of  TRANQUIL  concerned  with  procedures.  However,  certain  parts 
of  Section  3-2  dealing  with  PASS  2  implementation  will  be  useful  to  persons 
writing  programs  in  other  languages  which  will  commiinicate  with  TRANQUIL  pro- 
grams via  the  EXTERNAL  PROCEDURE  facility.   Finally,  as  a  brief  clarification 
of  what  has  been  said  here,  the  TRANQUIL  compiler  is  basically  divided  into 
two  passes  [3]*   In  the  first  pass,  the  source  code  is  parsed,  tables  are 
built  up,  and  the  intermediate  language  code  (which  is  far  simpler  than  the 
source  code)  is  generated.   The  second  pass  reads  the  intermediate  language 
code  and  takes  actions  on  the  various  operators,  using  also  the  tables  con- 
structed in  the  first  pass,  to  generate  assembly  code. 

3.1  Pass  1  Tables 

3.1.1  Use  of  IDTAB 

Two  principal  new  tables,  PARTAB  and  EXTTAB,  have  been  created  in 
the  TRANQUIL  compiler  for  use  in  handling  procedures.   In  addition,  the  already 
existing  table  IDTAB  is  used.   IDTAB  is  used  (in  connection  with  procedures)  to 
provide  an  entry  for  each  type  of  variable  (procedure  identifiers  or  para- 
meters) for  which  the  user  supplies  a  name  and  thus  allows  TRANQUIL  to  access 
the  correct  entry  every  time  that  the  name  appears  within  a  program.   EXTTAB 
is  used  to  save  the  name  assigned  by  the  user  to  an  EXTERNAL  PROCEDURE  or 
EXTERNAL  ENTRY  identifier  so  that  this  name  may  be  used  during  assembly  code 
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generation  in  PASS  2.  The  external  name  will  be  needed,  of  course,  so  that 
the  loader  may  properly  link  together  the  various  segments  to  make  the  com- 
plete program  required  by  the  user.  PARTAB  is  used  to  store  parameter  infor- 
mation for  parameters  which  are  not  assigned  names.   These  parameters  may 
occur  in  two  places:   the  EXTERNAL  ENTRY  declaration  and,  within  the  procedure 
heading,  as  the  parameters  of  a  procedure  passed  as  a  parameter. 

For  any  given  procedure  identifier,  there  is  a  field  in  its  IDTAB 
entry  known  as  NPARS  or  PARPTR  (this  is  one  field,  but  the  name  used  in  the 
coding  depends  on  the  usage  of  the  field) .   There  are  also  two  one  bit  fields 
which  are  of  interest  here,  EXTERML  and  PARAM.   One  or  neither  (but  not  both) 
of  these  bits  may  be  set  in  the  IDTAB  entry  for  a  procedure.   If  the  EXTERML 
bit  is  set,  then  the  PARPTR  field  points  to  EXTTAB.   If  the  PARAM  bit  is  set, 
the  PARPTR  field  points  to  PARTAB.   If  neither  of  these  bits  is  set,  then  the 
field  is  known  as  NPARS  and  it  contains  a  value  for  the  number  of  parameters 
each  of  which  will  have  an  entry  in  IDTAB  since,  in  this  case,  the  user  will 
have  assigned  an  explicit  name  to  each  formal  parameter. 

3.1.2  EXTTAB 

The  table  EXTTAB  is  used  to  hold  the  external  (user  assigned)  name 
so  that  it  may  be  output  during  PASS  2  generation  of  assembly  code.   The 
lengths  of  entries  in  EXTTAB  vary  depending  on  the  length  of  the  external 
name,  but  all  entries  are  at  least  two  words  long.   The  first  word  of  each 
entry  contains  the  number  of  characters  in  the  external  name,  a  pointer  to 
the  first  word  in  the  next  entry  in  EXTTAB,  and  a  pointer  to  PARTAB.   Entries 
in  EXTTAB  always  end  on  a  word  boundary  with  any  extra  characters  in  the  last 
word  being  filled  with  trailing  blanks. 
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3.1.3  PARTAB 

The  table  PARTAB,  as  mentioned  before,  is  used  to  hold  parameter 
information  for  parameters  which  are  given  attributes  only  (instead  of  ex- 
plicit names)  by  the  user.   The  type  of  information  stored  varies  with  the 
type  of  parameter  (set,  array,  etc.)  and  is  similar  to  the  information  stored 
in  IDTAB  for  the  same  tjrpe  of  variable  except  that  only  sufficient  infonnation 
is  stored  to  allow  complete  comparison  between  formal  and  actual  parameters. 

However,  since  procedures  used  as  parameters  may  themselves  have 
procedures  as  parameters  and  since  the  parameters  of  the  latter  procedures 
must  also  be  completely  specified,  PARTAB  must,  in  that  case,  have  a  tree 
structure.   Since  the  tree,  once  set  up,  is  not  changed  and  since  traversal 
is  always  top  down,  a  sequential  structure  devoid  of  any  threads  or  other 
backward  pointers  is  sufficient.  However,  for  convenience,  at  each  entry  for 
a  procedure  a  pointer  to  the  next  parameter  on  the  same  level  as  the  procedure 
is  maintained  (the  pointer  is  zero  if  the  procedure  is  the  last  parameter). 

The  first  word  of  an  entry  in  PARTAB  is  a  control  word.   This  word 
contains  the  number  of  first  level  parameters  (allowing  the  check  on  number  of 
parameters  to  be  made  before  the  parameters  are  actually  compared)  and  also 
the  number  of  words  in  the  entry  and  a  pointer  back  to  the  IDTAB  entry  which 
points  to  the  PARTAB  entry,  either  directly  or  through  EXTTAB. 

3.2  Pass  2  Actions 

3.2.1  Passing  Parameters 

Standard  methods,  as  specified  in  the  operating  system,  are  to  be 
used  in  passing  parameters  and  in  addressing  parameters  in  procedures.  There- 


21 


u 
<u 
-p 

•H 

O 

ft 


>3 


<V   -P 


EH 


^ 

o 

Ch 

>> 

0) 

-p 

^ 

C! 

•n 

0 

d) 

V 

9 

o 

M 

ft 

M 

H 

aJ 

4«i 


QJ 
-P 

•H 
O 
ft 


W  0) 

^  b 

<U  P     M 

-P  Ti   -H 

0  0) 

a  o  ^    q; 

c3  O   o 

CD  ft^ 

ft  15 

<=-  o 


-p 


Ph 


I 


l>5 

-p 

0) 


o 


w 
•H    ^ 

CO     (P     w 


rQ  'd  -p 

a  in  a 

p  O  0) 

fl  IS 


CD 


ft 


lM»4 


OJ 


ft 


0) 
(U  P 
0)    <D 

c3  o 

3  ft 
ft 


%*•! 


P> 


ft 


O    Tli 


QJ 
■P 

•H 
O 
ft 


-P  0) 
X  -P 
(D    CD 


H 
H 


CO   Eh 
K  Ph 

CM  <;  p:^  <;  S 

WXEhWcc;^<JhJ) 


•d 

0) 

o 
o 
u 
ft 

tiD 
•H 

o 

<H 

CO 

CO 
H 

-P 


w 
05 
P^ 

a 
a) 

-p 

CD 

ft 
•H 

CO 

si 
o 

•H 
-P 
05 
H 
(U 
^ 

0 

EH 


22 


fore,  anyone  writing  a  program  in  some  other  language  which  calls  a  procedure 
written  in  TRANQUIL  or  anyone  writing  an  external  procedure  in  another  lan- 
guage and  wishing  this  procedure  to  be  called  by  a  program  written  in  TRANQUIL 
must  adhere  to  the  operating  system  conventions  (at  the  time  of  this  writing, 
these  conventions  have  not  been  completely  specified) .  In  addition,  to  co- 
ordinate a  program  in  another  language  with  a  TRANQUIL  program,  one  should  be 
aware  of  what  is  passed  for  each  type  of  parameter.   Only  one  word  of  informa- 
tion need  be  passed  for  each  parameter;  this  infoirmation  will  now  be  described 
in  detail. 

3.2.1.1  Simple  Arithmetic  and  Boolean  Variables 

If  passed  by  address,  the  address  within  ILLIAC  IV  memory  of  the 
simple  variable  is  passed.   If  passed  by  value,  the  value  of  the  simple  vari- 
able is  passed.   In  addition,  for  each  parameter  passed  by  value,  a  bit  is 
set  in  the  value  word  (see  3'2.3  for  further  discussion  on  the  value  word). 

3.2.1.2  Sets 

For  a  set,  the  pointer  to  the  set  descriptor  table  location  for  the 
set  is  passed.  Briefly,  this  table,  which  resides  in  ILLIAC  IV  memory,  con- 
tains a  pointer  to  the  area  where  the  set  is  stored  and  indicates  whether  this 
area  is  in  SBLOCKORIGIN  or  MGSAFE.   For  further  discussion  on  set  structure, 
reference  should  be  made  to  Wilhelmson's  thesis  [h] . 

3.2.1.3  Arrays 

For  an  array,  an  array  descriptor  is  set  up  and  passed  as  a  para- 
meter.  This  array  descriptor  contains  two  2U-bit  fields,  stored  in  the  least 
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significaxit  portion  of  the  ILLIAC  IV  word.  The  first  (most  significant)  of 
these  fields  contains  a  pointer  to  DOPETB  (a  run-time  table  which  contains 
infonnation  about  the  number  and  size  of  dimensions  of  the  array)  and  the 
second  field  contains  a  pointer  to  BASETB  (a  run-time  table  which  contains 
pointers  to  the  actual  locations  where  the  array  blocks  are  stored).  Muraoka's 
thesis  [5]  gives  more  information  about  DOPETB  and  BASETB. 

3.2.1.4  Labels 

For  a  label,  nothing  is  passed  since  a  procedure  indicates  that  it 
is  jumping  to  a  label  by  setting  appropriate  bits  in  certain  ADB  locations, 
as  described  in  Section  3 -2.2  below. 

3«2.1.5  Procedures 

When  a  procedure  is  passed  as  a  parameter,  the  address  of  the  pro- 
cedure (i.e.,  the  address  at  which  the  executable  code  for  the  procedure 
begins)  is  passed. 

3.2.2  The  Procedure  Body 

The  entire  procedure  body  is  treated  as  a  separate  block.   In  addi- 
tion, subblocks,  as  created  by  the  user,  are  formed.  Any  block  which  the  user 
forms  within  the  procedure  occurs  as  a  subblock  of  the  procedure  block. 

In  forming  a  procedure  body,  code  is  first  generated  to  copy  para- 
meters, or  pointers  to  them,  from  the  calling  sequence  into  local  areas  in 
the  body.   Then  code  is  generated  which  translates  the  user's  TRANQUIL  source 
statements.  Finally,  code  is  generated  to  copy  back  parameters  if  necessary. 
The  copying  of  parameters  into  local  areas  is  required  due  to  the  lack  of 
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Figure  2.   The  structure  of  a  procedure  body  as 
generated  by  the  TRANQUIL  compiler 
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indirect  addressing  facilities  in  ILLIAC  IV.  Then,  in  order  to  pass  para- 
meters by  address  and  thus  obtain  new  values,  certain  parameters  must  be 
copied  back.   To  be  specific,  for  a  simple  variable,  the  value  is  copied  in- 
to a  local  area;  and,  if  the  parameter  is  passed  by  address,  the  value  is 
copied  back  at  the  end  of  the  procedure.  For  a  set,  the  pointer  to  the  set 
descriptor  table  is  copied  into  a  local  area  at  the  beginning  of  a  procedure 
and  copied  back  at  the  end  of  a  procedure.  For  an  array,  the  array  descrip- 
tor is  copied  into  a  local  area  at  the  beginning  of  a  procedure,  but  is  not 
copied  back  since  the  information  it  contains  is  not  subject  to  change.  For 
other  types  of  parameters,  no  copying  is  required. 

3'2.2.1  Returning  from  a  Procedure 

There  are  three  ways  in  which  a  return  may  be  made  from  a  TRANQUIL 
procedure:   execution  of  a  RETURN  statement,  jumping  to  a  label  passed  as  a 
parameter,  and  causing  the  execution  to  run  off  the  end  of  a  procediire.  How- 
ever, before  retiirn  can  be  made,  the  extra  portion  of  code  inserted  by  the 
compiler  at  the  end  of  a  procedure  (see  3*2.2  above)  must  be  executed.  This 
will,  of  course,  occur  automatically  when  the  execution  stream  goes  to  the 
end  of  a  procedure.   In  the  case  of  a  RETURN  statement  or  a  jump  to  a  label 
passed  a^  a  parameter,  a  jump  must  first  be  made  to  the  extra  code  at  the  end 
of  the  procedure  and,  at  the  same  time,  information  must  be  saved  as  to  the 
type  of  return  made  for  use  by  the  calling  program. 

Two  locations  in  the  ADB  are,  therefore,  set  aside  for  return  infor- 
mation.  These  are  known  as  RETURNLDB  and  RETURNLDBl.   Only  two  bits  are  used 
in  RETURNLDBl:   the  LABELRETURNBIT  and  the  VALURETURNBIT .   If  the  LABELRETURN- 
BIT  is  set,  then  RETURNLDB  will  have  a  bit  set  according  to  which  number 
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parameter  the  label  is.  Thus,  the  calling  program  need  only  check  RETURNLDB 
to  see  if  a  value  has  been  returned  or  a  jump  to  a  label  made  and  taJte  the 
appropriate  action  using  information  stored  in  RETURNLDBl. 

3.2.3  The  Procedure  Call 

When  calling  a  procedure,  the  parameter  information  is  stored  in  an 
area  known  as  the  parameter  block  which  immediately  follows  the  procediore  call 
and  is  then  addressed  relative  to  the  parameter  block.  The  first  word  of  the 
parameter  block  is  the  value  word  which  contains  one  bit  for  each  parameter 
(thus  limiting  the  number  of  parameters  of  any  procedure  to  6^  in  the  current 
implementation).   If  the  bit  is  set,  the  parameter  is  passed  by  value.  For 
each  parameter  which  is  declared  as  being  passed  by  value  in  the  procedure 
heading,  the  corresponding  bit  is  set.   In  addition,  if  an  actual  parameter 
corresponding  to  a  call  by  address  formal  parameter  is  an  expression,  then  the 
corresponding  bit  is  set,  thus  allowing  implicit  call  by  value  as  described 
above. 

The  parameter  block  then  consists  of  n  +  1  words,  where  n  is  the 
niimber  of  parameters.   The  parameter  information  (as  described  in  Section  3 -2.1 
above)  for  the  i-th  parameter  is  placed  in  the  i-th  parameter  word  following 
the  value  word.  When  an  expression  is  encountered  (corresponding  to  a  simple 
arithmetic  or  boolean  formal  parameter),  the  expression  is  evaluated  using 
routines  built  into  the  TRANQUIL  compiler  to  handle  assignment  statements  and 
the  result  is  placed  in  the  appropriate  word  in  the  parameter  block. 

Certain  changes  may  be  required  in  the  above  scheme  as  work  on  the 
operating  system  progresses  in  order  to  fully  coordinate  TRAI^QUIL  with  the 
operating  system.  Also,  should  it  be  deemed  necessary,  it  woiiLd  be  relatively 
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easy  to  increase  the  limit  on  the  number  of  parameters  by  forming  an  additional 
value  word.  An  area  to  evaluate  the  information  returned  by  the  procedure 
follows  the  procedure  call  and  the  parameter  block.  First,  the  LABELRETURNBIT 
bit  in  RETURNLDBl  is  checked.  If  the  bit  is  reset,  then  the  entire  label  area 
is  skipped.   Otherwise,  the  bits  which  may  correspond  to  labels  are  checked  in 
succession  until  one  is  found  set  and  a  jump  to  the  appropriate  label  is  made. 
If  the  VALUEETUKNBIT  bit  in  RETURNLDBl  is  set,  then  the  value  is  loaded  from 
RETURMjDB  to  RGA  of  all  PE's  to  be  used  in  the  expression  (if  any)  in  which 
the  procedure  call  resides. 

3.2.4  Linking  Procedure  Calls  to  Expressions 

In  order  to  allow  procedure  calls  (to  typed  procedures)  to  be  em- 
bedded in  expressions  and  in  order  to  allow  general  expressions  (including 
proced-ure  calls)  to  appear  as  parameters,  what  is  essentially  the  ILCODE 
(intermediate  language  code)  for  the  entire  procediire  call  is  pushed  into 
array  ARITHSTACK  and  then,  at  the  end  of  the  statement,  is  evaluated  in 
procedure  EXEC2GC  so  that  the  innermost  expressions  are  evaluated  first.  Es- 
sentially the  same  scheme,  with  minor  changes,  works  for  ordinary  procedures 
in  statements  not  imder  SIM  control  and  also  for  ROW  procedures  in  statements 
under  siM  control.  Budnik's  thesis  [3]  contains  further  details  of  this 
scheme  for  handling  exi)ressions. 
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h.     M  EXTENSION 

k.l     Introduction  to  Array  Procedures 

On  conventional  machines,  most  algebraic  compilers  have  procedures 
or  subroutines  which  are  capable  of  returning  a  single  ,^lue.  Since  ILLIAC 
IV  is  intended  to  be  a  parallel  array-processing  machine,  it  would  seem 
logical  to  have,  in  TRANQUIL,  procediires  which  would  be  capable  of  returning 
an  entire  array  of  values.  ROW  procedures,  in  very  restricted  cases,  have 
this  capability  but  they  return  only  a  row  of  values  (i.e.,  across  64  or  less 
PE's)  and  must  be  written  in  assembly  language. 

However,  array  procedures  present  some  special  problems.   The  first 
of  these  is  a  storage  problem  for  the  resultant  array.  When  a  single  value 
is  returned,  a  single  word  or  register  may  be  used  to  store  the  value.   In  a 
single  quadrant  ILLIAC  IV,  it  could  be  reasonably  assumed  that  up  to  6k   values 
could  be  returned  in  this  fashion  by  using  a  designated  register  in  each  PE  or 
by  setting  aside  a  designated  row  of  PE  memory  exclusively  for  values  retiirned 
from  the  procedure.   Such  methods  would  be  fine  if  TRANQUIL  were  a  row  language, 
but  it  is  not.  For  array  procedures  to  be  meaningfiol  in  TRANQUIL,  the  arrays 
which  are  returned  must  be  general  and  must  correspond  to  arrays  which  may  be 
declared  in  TRANQUIL  programs.   The  storage  problem  then  arises  since  ILLIAC 
rv  memory  is  rather  small  in  comparison  with  some  of  the  arrays  which  are 
expected  to  occur  in  various  applications.  Additional  arrays,  to  be  associated 
with  procedures,  would  fill  up  memory  even  more.  A  good  fast  overlay  scheme 
would  allay  many  of  these  difficulties  and  perhaps  make  it  possible  to  imple- 
ment array  procedures  in  a  reasonable  fashion.  Users  of  TRANQUIL  would,  no 
doubt,  find  array  procedures  very  convenient,  particularly  when  dealing  with 
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array  operations.  Some  additional  uses  for  array  procedures  will  be  presented 
later. 

k.2     Proposed  Specifications  for  Array  Procedures 

Since  array  procedures  are  both  arrays  and  procedures,  their  speci- 
fication must  contain  both  array  and  procedure  information.  The  array  infor- 
mation would  consist  of  type  of  array,  mapping  function,  and  nijmber  and 
bounds  of  dimensions.  The  proced\ire  information  would  consist  of  parameter 
specifications  and,  of  course,  the  procedure  body. 

However,  to  give  greater  freedom,  a  distinction  could  be  made  be- 
tween two  types  of  array  procedures,  STATIC  and  DYMMIC.   The  difference  be- 
tween the  two  is  that  the  bounds  on  each  dimension  of  a  STATIC  procedure  are 
fixed  at  the  declaration  whereas  the  bounds  for  a  DYNAMIC  procedure  are  dif- 
ferent at  each  procedure  call  and,  if  specified  by  variables,  may,  in  fact, 
change  every  time  the  procediire  call  is  executed.   Therefore,  the  array  asso- 
ciated with  a  STATIC  array  procedure  would  be  exactly  like  any  other  array 
declared  in  the  TRANQUIL  program  and  the  block  with  which  this  array  would  be 
associated  would,  of  course,  be  the  block  in  which  the  procedure  declaration 
appeared.   On  the  other  hand,  the  DYTMMEC  array  size  changes  after  each  pro- 
cedure call  and  the  array  as  such  does  not  come  into  existence  until  a  pro- 
cedure call  is  executed.   For  the  DYKAMIC  array,  the  mapping  function  and 
number  of  dimensions  does  not  change. 

As  an  example,  consider  the  following  first  part  of  the  specification 
of  a  STATIC  array  procedure : 

STATIC  REAL  SKEWED  ARRAY  PROCEDURE  P(A)   [0:10,  1:6^+]; 
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This  indicates  that  P  is  an  array  procedure  with  one  parameter  A  (the  para- 
meter A  would  be  specified  as  elsewhere  in  TRANQUIL  and  so  does  not  concern 
us  here)  and  that  the  array  associated  with  the  procedure  is  a  REAL  SKEWED 
array  of  two  dmensions,  the  first  of  which  is  11  long  aad  the  second  6U.  If 
P  is  to  be  a  DYNAMIC  procedure,  then  the  declaration  is: 

DYNAMIC  REAL  SKMED  ARRAY  PROCEDURE  P(A)   [*,*]; 

which  is  the  same  as  above  except  that  the  bounds  of  the  dimensions  must  be 
specified  in  the  calling  statement. 

Since  an  array  procedure,  when  called,  would  generate  an  entire 
array  of  values  in  memory,  it  would  seem  wasteful  not  to  have  this  array  avail- 
able for  use  after  the  statement  in  which  the  array  procedure  occurred.   How- 
ever, the  problem  then  arises  of  being  able  to  syntactically  distinguish  be- 
tween a  call  to  the  procedure  and  a  use  of  the  array.  A  possible  way  to  do 
this  would  be  to  use  the  word  "CALL"  to  indicate  a  procedure  call  which  would 
fill  up  the  array  and  then  to  use  the  procedure  name  in  following  statements 
just  as  one  would  use  any  other  array.   For  instance,  for  the  array  procedure 
P,  if  declared  STATIC  as  in  the  first  example  above,  we  could  write: 

CALL  P(X); 
Z:  =  P[l,  2]; 

noting  that  the  parameter  appears  in  the  CALL  but  not  in  the  use  of  the  array. 

When  a  DYNAMIC  array  procedujre  is  called,  additional  information 
must  be  supplied  in  order  to  give  the  bounds  of  the  dimensions  for  this  partic- 
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ular  call.   The  most  obvious  method  is  to  specify  the  bounds  in  the  call. 
Thus,  if  P  is  the  DYNAMIC  array  procedure  from  the  second  example  above,  we 
could  write: 

GALL  P(X)   [l:10,l:6i+]; 

where,  of  course,  arithmetic  expressions  could  also  be  used  in  the  brackets 
with  the  understanding  that  the  array  take  the  bounds  determined  by  evaluating 
the  arithmetic  expression(s)  before  the  procedure  call  occurs.  Another  in- 
teresting possibility  would  be  to  have  the  bounds  take  on  the  bounds  of  some 
other  array.   This  could  be  specified  by  writing: 

CALL  P(X)   (b); 

where  B  is  some  two  dimensional  array,  and  the  second  set  of  parentheses  pro- 
vides a  convenient  method  for  signalling  the  parser  that  an  array  identifier 
is  being  used  to  supply  the  bounds  as  opposed  to  an  array  element  appearing 
in  some  arithmetic  expression. 

k.3     Applications 

U.3.1  Kapping  Functions 

An  interesting  application  of  array  procedures  would  be  for  use  in 
creating  non-standard  mapping  functions  for  special  applications.   It  is  well 
known  that,  for  various  problems,  maximum  efficiency  of  use  of  ILLIAC  IV  is 
achieved  by  having  the  array  elements  arranged  in  a  special  fashion.  Thus, 
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axi  array  procedure  could  be  used  to  build  up  an  array  of  elements  in  a  special 
fashion  by  use  of  the  CALL.  Then  the  array  could  be  used  in  the  application 
and  subsequently,  perhaps,  another  array  procedure  could  be  used  to  bring  the 
array  to  a  different  mapping  function.  Of  course,  the  TRANQUIL  generated  code 
would  work  on  the  array  as  if  it  were  in  one  of  the  standard  mapping  functions 
(straight,  skewed,  etc.),  but  the  procedure  would  have  manipulated  the  elements 
in  such  a  fashion  that  in  reality  the  operations  would  be  performed  on  the 
elements  under  a  different  mapping  function.   In  particular,  by  using  DYNAMIC 
array  procedures,  the  same  array  procedure  could  be  used  to  convert  a  variety 
of  arrays  to  the  new  mapping  function. 

U.3.2  Input /Output 

Another  possible  interesting  use  of  array  procedures  could  be  in 
Input /output .   The  array  procedure  could  act  like  a  singly  buffered  input- 
output  routine.  Whenever  the  array  procedure  is  called,  the  resultant  array 
could  be  filled  from  an  input  file,  the  array  elements  could  be  used  as  needed, 
and  the  procedure  could  be  called  again  to  refill  the  array.  On  the  other 
hand,  the  array  procediire  could  be  used  to  build  up  an  array  which  could  then 
be  written  on  the  output  file  and  the  array  procediire  could  be  called  again 
to  refill  the  array,  and  so  forth. 
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5 .   CONCLUSION 

A  procedure  structure  has  been  provided  in  TRANQUIL  which  allows 
the  user  to  write  internal  procedures  in  TRANQUIL  and  external  procedures  in 
TRANQUIL  or  any  other  language  which  is  able  to  meet  TRANQUIL  specifications. 
Any  TRANQUIL  constructs  may  be  passed  as  parameters  and  procedures  may  or  may 
not  return  single  values.  Recursion  is^  however,  not  allowed. 

Essential  work  has  been  completed  on  the  procedure  structure  in 
TRANQUIL,  but  a  relatively  small  amount  of  work  will  be  required  to  complete 
interface  with  the  ILLIAC  IV  operating  system  which  is  currently  being  de- 
veloped.  To  this  end,  the  procedure  structure  has  been  kept  flexible. 
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APPEKDIK  A 

THE  SYOTAX  OF  PROCEDURES 
The  syntax  given  here  for  procedures  is  a  portion  of  the  entire 
syntax  for  TRANQUIL  as  input  to  the  translator  writing  system  except  that 
calls  to  semantic  actions,  which  wo\ild  not  be  relevant  here,  have  been  de- 
leted. The  syntax  is  similar  to  BNF,  but  there  are  certain  differences  which 
facilitate  processing  [6] .  The  main  differences  in  the  syntax  appearing  here 
are:   the  use  of  "&"  to  indicate  one  or  no  occurrences  of  a  construct;  the  use 
of  quotes  to  surroTjnd  metalinguistic  variables;  the  use  of  "/"  in  place  of  the 
vertical  bar  to  indicate  an  alternative;  the  use  of  the  LIST -SEPARATOR -CLOSE 
construct  to  indicate  left  recursion;  the  use  of  "*I"  to  indicate  any  per- 
missible identifier;  the  use  of  "■'^N"  to  indicate  any  permissible  number;  and 
the  use  of  "#"  to  precede  reserved  words  and  also  reserved  characters  when  the 
latter  are  to  appear  in  the  language  itself. 
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SYNTAX  OF  PROCEDUPES  IN  TRANOUlL 

♦♦PROCEDURE  OECLARATION*  ll«  [  ♦♦ATTRIBUTE^'   H  IPROCEnURr 
♦♦*!♦♦   [♦♦PROCEDURE  HEADING^^  $t       f    ill 
♦•KUM  EMPTY  STATEMENT**    I 
♦•FXTERNAl  PROCEDURE  OECL  ARAT  InN«^  tie  *EXTERNA| 

♦•PROCEDURE  DECLARATION^'  \ 
♦•PROCEDURE  hEADING^^  ll«  (LIST  [  ♦♦*!♦♦   1  SEPARATOR  »    CLOSE-* 

#;  [LIST  [  #VAIUE  LIST  C  ♦♦*I^'   )  SEPARATOR  .  CLO«;E] 
SEPARATOR  t\    CLOSE  #1   1« 

LIST  [♦♦SPECIF  ICATION**  1  SEPARATOR  t\    ClOsF  I 
♦•SPECIFICATION^^  »l«  ♦♦ARRAY  SPF  C IFI CATION^^  / 
♦•PROCEDURE  SPECIFICATION*'  / 

♦♦ATTRIPUTE^^  LIST  [  ♦♦♦I^'    ]  SEPARATOR  ,  CLOSE  / 
ILAPEL   LIST  [  "♦I^^   ]  SEPARATOR  #  C|  OSE  / 


fSHlTCK   LIST  [  ♦♦*!♦♦   1  SFPAfiATOR  ,  cLoSF  / 
LIST  [  ♦'SET  ATTHTPUTf"   LIST  [♦'*I"   ] 

SEPAPA70R  *  CLOSE  1   SEPARATOR  .  CLOSf; 
♦♦ARRAY  SPECIFICATION^^  ll«  ♦'ARRAY  ATTRIBUTE^'  LIST  [ 

LIST  [♦♦*!♦•  ]  SEPARATOR  ,    CLOSf 
t[   LIST  C  f*    /  ♦♦♦N^^   ] 
SEPARATOR  ,  CLOSF  #3   1  SEPARATOR  »  CLOSE) 
♦•PROCtrURE  SPECIFICATION**  l««  [♦♦ATTRIBUTE"   ]  & 

[  tROk  3&  IPROCEDUHF 

♦•♦I^*    [  (   LIST   [♦•PARAMETER  SPEC  IF  I  CAT  I ONS^^  ] 

SEPARATOR  ,  CLOSF  )UI 

♦•PARAMETtR  SPEC  I  F  I  C  AT  I  ONS'^  ll«  ♦'ARRAY  ATTRIPuTF" 
»(  LIST  [  #*    J  SEPARATOR  ,  CLOSE  #1   / 

[   ♦•ATTRIBUTE*'   )  R  [  *ROw   ]  K    fPROCEOURE 

[  {   LIST  ["PARAMETER  SPECIFICATIONS"  ]  SEPARATOR  # 
CLOSE  )    ]&  / 
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[  fVALliE    n    ♦'ATTRIBUTE'*   / 

#LABFL  / 
iSWiTCH  / 
"SET  ATTRIRUTE**   I 

"EXTERNAL  ENTRY  DECLARATION"  tl«  lEVTERNAL 

t  "ATTRIPUTE"   ]  &   r  *ROW   ]  &   «ENTRV 

"♦I"   [  (   LIST  "PARAMETER  SPECIFICATIONS" 
SEPARATOR  *  CLOSE  )   U  ) 

"PROCEDURE  CALL"  ll»  "ROfc^  PROCFOURF  CALL"  /  "SIMPLE  PPnCEDi"' E  CALL") 
"ROW  PROCEDURE  CALL"  «««  "*I"   ( 

"ARITHMETIC  EXPRESSION"   )  i 
"SIMPLE.  PROCEDURE  CALL"  l««  "*I"   [(   LIST 

"ACTUAL  PARAMETER"  SEPARATOR  I*       ]  CLOSE)   U  I 
"ACTUAL  PARAMETER"  Jl»  "*T"   f  AHEAD  »     /    AHFAT  )  1   / 
[  "PPOIEAN  EXPRESSION"   / 

"ARITHMETIC  EXPRESSlTN"   3    I 
"RETURN  STATEMENT"   its  tRFTURN  K   ["ARITHMETIC  ExPRESSIOk." 
/  "pnOLEAN  EXf-RESSlON**   ])]4  t 
"ARRAY  ATTRIBUTE"  l««  "ATTRlPUTE"   f  KSKFWED  tPArKEO    / 
tSKEWED   / 
iSTRAIGHT  tpACKED  / 
tSTRAIGHT   / 
fCHECKER   ]  I 
tAPPAY   ; 
"SET  ATTRlPUTE"  H«  UNCSET   /  fMONOSET  /  #f,ENSET  f 
"ATTPTFUTE"! I*   IBOOlEAN  /   #RrAl   /  fPFALS  /  tPEALP  / 

^INTEGER  /  #PYTE8  /  IPYTE16  /  fiNTEGERS  / 
tiNTFGERL  ) 
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APPENDIX  B 

SAMPLE  TRAITQUIL  PROGRAM  USING  PROCEDURES 

The  TRANQUIL  program  shown  below  is  intended  to  illustrate  procedure 
declarations  and  calls.   Procedures  are  used  to  do  smaller  tasks  than  would  be 
the  normal  case.  An  external  procedure  is  given  along  with  a  main  program 
which  calls  the  external  procedure  and  some  internal  procedures.  As  mentioned 
before,  the  external  procedure  and  main  program  would  receive  separate  compi- 
lation and  assembly. 

The  external  procedure : 

EXTERML  REAL  PROCEDURE  SQUARE  (A); 

VALUE  A;   REAL  A; 

BEGIN 

IF  A  <  .01  THEN  A:=0; 

RETURN  (A  X  A); 

END; 

The  main  program: 

BEGIN 

REAL  STRAIGHT  ARRAY   A,B,C  [1:6^+,  1:64]; 

INTEGER  I,  J; 

INCSET  II; 

MONOSET  M; 

PROCEDURE  SMM  (X,  Y,  Z,  W,  K); 

VALUE     K; 

REAL     STRAIGHT     ARRAY     X,    Y,    Z   [*,    *] ; 

MONOSET  W; 

INTEGER  K; 

BEGIN 

INTEGER  I; 

FOR   (I)      SIM  (W)      DO 

Z  [I,K]    :   =  X  [I,K]   +  2  X  Y  [l,K]; 
END; 
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REAL  PROCEDURE  LENGTH  (A,  M) ; 

REAL  STRAIGHT  ARRAY  A  [*,*]} 

INCSET  M; 

BEGIN 

EXTERNAL  REAL  ENTRY  SQUARE  (VALUE  REAL); 

REAL  S; 

S:  =  0; 

FOR  (I)   SEQ  (M)   do 

S:   =  S  +  SQUARE  (A[I,I]); 
RETURN  (S); 
END; 

M  :  =  [1,  2,    ...,   6k]i 
II  :  =  [1,  2,    ...,   61+]; 

IF  LENGTH  (A, II)  >  LENGTH  (B,II)   THEN 
BEGIN 

FOR  (J)   SEQ  (II)   DO 

34M  (A,   B,    C,  M,   J); 
END  ELSE 
BEGIN 

FOR   (J)      SEQ     (II)      DO 

SMM  (B,  A,    C,   y[,   J); 
END; 
END. 
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